---
redirect_from:
  - /deployment/production-checklist
---

# Production checklist

<InfoBox>

Thinking of migrating to the cloud instead? [Click
here][blog-migrate-to-cube-cloud] to learn more about migrating a self-hosted
installation to [Cube Cloud][link-cube-cloud].

</InfoBox>

This is a checklist for configuring and securing Cube for a production
deployment.

## Disable Development Mode

When running Cube in production environments, make sure development mode is
disabled both on API Instances and Refresh Worker. Running Cube in development
mode in a production environment can lead to security vulnerabilities. Enabling
Development Mode in Cube Cloud is not recommended. Development Mode will expose
your data to the internet. You can read more on the differences between
[production and development mode here][link-cubejs-dev-vs-prod].

<InfoBox>

Development mode is disabled by default.

</InfoBox>

```dotenv
# Set this to false or leave unset to disable development mode
CUBEJS_DEV_MODE=false
```

## Set up Refresh Worker

To refresh in-memory cache and [pre-aggregations][ref-schema-ref-preaggs] in the
background, we recommend running a separate Cube Refresh Worker instance. This
allows your Cube API Instance to continue to serve requests with high
availability.

```dotenv
# Set to true so a Cube instance acts as a refresh worker
CUBEJS_REFRESH_WORKER=true
```

## Set up Cube Store

<WarningBox>

While Cube can operate with in-memory cache and queue storage, there're multiple
parts of Cube which require Cube Store in production mode. Replicating Cube
instances without Cube Store can lead to source database degraded performance,
various race conditions and cached data inconsistencies.

</WarningBox>

Cube Store manages in-memory cache, queue and pre-aggregations for Cube. Follow
the [instructions here][ref-caching-cubestore] to set it up.

Depending on your database, Cube may need to "stage" pre-aggregations inside
your database first before ingesting them into Cube Store. In this case, Cube
will require write access to a dedicated schema inside your database.
The schema name is `prod_pre_aggregations` by default. It can be set using the
[`pre_aggregations_schema` configration option][ref-conf-preaggs-schema].

<InfoBox>

You may consider enabling an export bucket which allows Cube to build large
pre-aggregations in a much faster manner. It is currently supported for
BigQuery, Redshift, Snowflake, and some other data sources. Check [the relevant
documentation for your configured database][ref-config-connect-db] to set it up.

</InfoBox>

## Secure the deployment

If you're using JWTs, you can configure Cube to correctly decode them and inject
their contents into the [Security Context][ref-sec-ctx]. Add your authentication
provider's configuration under [the `jwt` property of your `cube.js`
configuration file][ref-config-jwt], or if using environment variables, see
`CUBEJS_JWK_*`, `CUBEJS_JWT_*` in the [Environment Variables
reference][ref-env-vars].

## Set up health checks

Cube provides [Kubernetes-API compatible][link-k8s-healthcheck-api] health check
(or probe) endpoints that indicate the status of the deployment. Configure your
monitoring service of choice to use the [`/readyz`][ref-api-readyz] and
[`/livez`][ref-api-livez] API endpoints so you can check on the Cube
deployment's health and be alerted to any issues.

## Appropriate cluster sizing

There's no one-size-fits-all when it comes to sizing a Cube cluster and its
resources. Resources required by Cube significantly depend on the amount of
traffic Cube needs to serve and the amount of data it needs to process. The
following sizing estimates are based on default settings and are very generic,
which may not fit your Cube use case, so you should always tweak resources based
on consumption patterns you see.

### Memory and CPU

Each Cube cluster should contain at least 2 Cube API instances. Every Cube API
instance should have at least 3GB of RAM and 2 CPU cores allocated for it.

Refresh workers tend to be much more CPU and memory intensive, so at least 6GB
of RAM is recommended. Please note that to take advantage of all available RAM,
the Node.js heap size should be adjusted accordingly by using the
[`--max-old-space-size` option][node-heap-size]:

```sh
NODE_OPTIONS="--max-old-space-size=6144"
```

[node-heap-size]:
  https://nodejs.org/api/cli.html#--max-old-space-sizesize-in-megabytes

The Cube Store router node should have at least 6GB of RAM and 4 CPU cores
allocated for it. Every Cube Store worker node should have at least 8GB of RAM
and 4 CPU cores allocated for it. The Cube Store cluster should have at least
two worker nodes.

### RPS and data volume

Depending on data model size, every Core Cube API instance can serve 1 to 10
requests per second. Every Core Cube Store router node can serve 50-100 queries
per second. As a rule of thumb, you should provision 1 Cube Store worker node
per one Cube Store partition or 1M of rows scanned in a query. For example if
your queries scan 16M of rows per query, you should have at least 16 Cube Store
worker nodes provisioned. Please note that the number of raw data rows doesn't
usually equal the number of rows in pre-aggregation. At the same time, queries
don't usually scan all the data in pre-aggregations, as Cube Store uses
partition pruning to optimize queries. `EXPLAIN ANALYZE` can be used to see
scanned partitions involved in a Cube Store query. Cube Cloud ballpark
performance numbers can differ as it has different Cube runtime.

[blog-migrate-to-cube-cloud]:
  https://cube.dev/blog/migrating-from-self-hosted-to-cube-cloud/
[link-caddy]: https://caddyserver.com/
[link-cube-cloud]: https://cubecloud.dev
[link-cubejs-dev-vs-prod]: /product/configuration#development-mode
[link-k8s-healthcheck-api]:
  https://kubernetes.io/docs/reference/using-api/health-checks/
[link-kong]: https://konghq.com/kong/
[link-nginx]: https://www.nginx.com/
[link-nginx-docs]: https://nginx.org/en/docs/http/configuring_https_servers.html
[ref-config-connect-db]: /connecting-to-the-database
[ref-caching-cubestore]: /product/caching/running-in-production
[ref-conf-ref-env-cachequeue-driver]:
  /reference/configuration/environment-variables#cubejs_cache_and_queue_driver
[ref-conf-preaggs-schema]: /reference/configuration/config#pre_aggregations_schema
[ref-env-vars]: /reference/configuration/environment-variables
[ref-schema-ref-preaggs]: /reference/data-model/pre-aggregations
[ref-sec-ctx]: /product/auth/context
[ref-config-jwt]: /reference/configuration/config#jwt
[ref-api-readyz]: /reference/rest-api#readyz
[ref-api-livez]: /reference/rest-api#livez
